Software Components as Invariant-Typed Arrows - (Keynote Talk)

Invariants are constraints on software components which restrict their behavior in some desirable way, but whose maintenance entails some kind of proof obligation discharge. Such constraints may act not only over the input and output domains, as in a purely functional setting, but also over the underlying state space, as in the case of reactive components. This talk introduces an approach for reasoning about invariants which is both compositional and calculational: compositional because it is based on rules which break the complexity of such proof obligations across the structures involved; calculational because such rules are derived thanks to an algebra of invariants encoded in the language of binary relations. A main tool of this approach is the pointfree transform of the predicate calculus, which opens the possibility of changing the underlying mathematical space so as to enable agile algebraic calculation. The development of a theory of invariant preservation requires a broad, but uniform view of computational processes embodied in software components able to take into account data persistence and continued interaction. Such is the plan for this talk: we first introduce such processes as arrows, and then invariants as their types. 1 Components as arrows Probably the most elementary model of a computational process is that of a function f : I −→ O, which specifies a transformation rule between two structures I and O. In a (metaphorical) sense, this may be dubbed as the ‘engineer’s view’ of reality: here is a recipe to build gnus from gnats. Often, however, reality is not so simple. For example, one may know how to produce ‘gnus’ from ‘gnats’ but not in all cases. This is expressed by observing the output of f in a more refined context: O is replaced by O + 1 and f is said to be a partial function. In other situations one may recognise that there is some context information about ‘gnats’ that, for some reason, should be hidden from input. It may be the case that such information is huge to be give as a parameter to f , or shared by other functions as well. It might also be the case that building gnus would eventually modify the environment, thus influencing latter production of more ‘gnus’. For U a denotation of such context information, the signature of f becomes f : I −→ (O × U) . In both cases f can be typed as f : I −→ T O, for T = Id + 1 and T = (Id × U) , respectively, where, intuitively, T is a type transformer providing a shape for the output of f . Technically, T is a functor which, to facilitate composition and manipulation of such functions, is often required to be a monad. In this way, the ‘universe’ in which f : I −→ T O lives and is reasoned about is the Kleisli category for T . In fact, monads in functional programming offer a general technique to smoothly incorporate, and delimit, ‘computational effects’ of this kind without compromising the purely functional semantics of such languages, in particular, referential transparency. A function computed within a context is often referred to as ‘state-based’, in the sense the word ‘state’ has in automata theory — the memory which both constrains and is constrained by the execution of actions. In fact, the ‘nature’ of f : I −→ (O×U) as a ‘state-based function’ is made more explicit by rewriting its signature as f : U −→ (O × U) This, in turn, may suggest an alternative model for computations, which (again in a metaphorical sense) one may dub as the ‘natural scientist’s view’. Instead of a recipe to build ‘gnus’ from ‘gnats’, the simple awareness that there exist gnus and gnats and that their evolution can be observed. That observation may entail some form of interference is well known, even from Physics, and thus the underlying notion of computation is not necessarily a passive one. The able ‘natural scientist’ will equip herself with the right ‘lens’ — that is, a tool to observe with, which necessarily entails a particular shape for observation. Similarly, the engineer will resort to a ‘tool box’ emphasizing the possibility of at least some (essentially finite) things being not only observed, but actually built. In summary, an observation structure: universe c −→ ©_© universe an assembly process: e e artifact a −→ artifact Assembly processes are specified in a similar (but dual) way to observation structures. Note that in the picture ‘artifact’ has replaced ‘universe’, to stress that one is now dealing with ‘culture’ (as opposed to ‘nature’) and, what is far more relevant, that the arrow has been reversed. Formally, both ‘lenses’ and ‘toolboxes’ are functors. And, therefore, an observation structure is a ©_©coalgebra, and an assembly process is a e e -algebra. Algebras and coalgebras for a functor [13] provide abstract models of essentially construction (or data-oriented) and observation (or behaviour -oriented) computational processes, respectively. Construction compatibility and indistinguishability under observation emerge as the basic notions of equivalence which, moreover, are characterized in a way which is parametric on the particular ‘toolbox’ or ‘lens’ used, respectively. Algebraic compatibility and bisimilarity acquire a shape, which is the source of abstraction such models are proud of. Moreover, it is well known that, if ‘toolboxs’ or ‘lens’ are ‘smooth enough’, there exist canonical representations of all ‘artifacts’ or ‘behaviours into an initial (respectively, final) algebra (respectively, coalgebra). Both assembly and observation processes, as discussed above, can be modeled by functions, or more generally, by arrows in a suitable category, between the universes-of-interest. Both aspects can be combined in a single arrow